在許多軟體團隊實踐 SBE（Specification By Example）或使用 Gherkin 撰寫需求場景時，經常會面對一個共同困擾：舊的 scenario 又長又雜亂，不僅難以閱讀，更讓日後的維護與溝通充滿障礙。

特別是當產品經歷多次功能調整、團隊成員異動時，這些歷史包袱會讓人望而卻步。

其實，重構與精煉這些舊場景的過程，不只是技術負債的清理，更是團隊重新對齊需求認知、挖掘業務語言、推動產品演進的好機會。

這篇範例將透過一個圖書館借書系統的故事，模擬如何循序漸進地對舊 scenario 進行 refactoring，並在新功能加入時，讓情境持續演進，最終達成清晰、可協作的需求文件。

範例主題：圖書館借書系統

背景介紹

「Library+」是一個讓讀者線上搜尋圖書、預約與借書的平台。最近圖書館發現，有許多讀者預約後卻未取書，導致書籍閒置、浪費資源。產品負責人（PO）Joanna 被要求新增提醒功能，降低預約後未取書的情形。她召集開發、測試和 UX 夥伴，開始從現有舊 scenario 著手。

團隊成員角色：
• Andy — developer
• Nina — tester
• Joanna — product owner
• Karl — user experience

1. 舊場景（Listing 1）
   Scenario: Library Borrow Test
   Given the time is "09:00"
   Given a user goes to "http://test.libraryplus.com/"
   And they fill in "Data Science" in "SearchBox"
   When they press "Search"
   Then they should see "Data Science Handbook" in "Results"
   And they select "Data Science Handbook"
   When they press "Reserve"
   Then they should see "Reserved" in "Status"
   When they go to "My Reservations"
   Then they should see "Data Science Handbook" in "ReservedBooks"
   And they see "Ready for Pickup" in "ReservationStatus"

(1) 第一次 Refactoring：命名聚焦、拆分規則、去除雜訊

A. 團隊對話
Joanna：「這 scenario 寫得像操作手冊，沒寫出我們要的業務規則，也沒聚焦在預約流程上。」
Nina：「裡面一堆細節根本不需要，像網址、搜尋框、按鈕這些，都只是介面實作。」
Karl：「我們應該聚焦『預約圖書成功』這個業務結果，把細節留給自動化測試寫法就好。」

B. 調整後 Listing 2：
Scenario: Reader reserves a book for pickup
Given a reader wants to borrow a book
When they reserve an available book
Then the reservation is successful
And the book status is "Ready for Pickup"

C. 本次做法：
• 用業務語言命名 scenario
• 移除多餘 UI 細節，只留下業務意圖
• 聚焦於「預約成功」這條規則

(2) 第二次 Refactoring：精簡步驟，揭露意圖，去除雜訊資料

A. 團隊對話
Joanna：「『reader wants to borrow a book』還是太抽象，要不要更明確地指出預約情境？」
Andy：「而且最後那行跟前面重複了，狀態『Ready for Pickup』就是預約成功。」
Nina：「那我們應該只需要一句：預約後，該書的狀態變成『Ready for Pickup』。」

B. 調整後 Listing 3：
Scenario: Reader reserves an available book
Given a book is available
When a reader reserves the book
Then the book status becomes "Ready for Pickup"

C. 本次做法：
• 直接點出預約主角（reader）、動作（reserves）、對象（available book）
• 去除與業務無關的假資料和重複描述
• 讓每一行揭露業務意圖，而不是技術細節

(3) 第三次 Refactoring：聚焦單一規則，預留新需求空間

A. 團隊對話
Joanna：「我們後續要新增提醒功能，若預約後三天沒取書要自動取消。那這 scenario 是否要補充『取書』相關規則？」
Karl：「可以，這樣 scenario 在新功能加入時才能一起演進，成為產品行為的共同語言。」
Nina：「那我們需要拆分情境：一個描述『預約成功』，一個描述『未取書而自動取消』。」

B. 調整後 Listing 4：
（a）預約成功
Scenario: Reader reserves an available book
Given a book is available
When a reader reserves the book
Then the book status becomes "Ready for Pickup"

（b）新功能：逾期未取書自動取消
Scenario: Reservation is cancelled if the book is not picked up within 3 days
Given a reader has reserved a book
And 3 days have passed since the book became "Ready for Pickup"
When the reader has not picked up the book
Then the reservation is cancelled
And the book status becomes "Available"

C. 本次做法：
• 將新規則（自動取消）拆成獨立 scenario，聚焦單一業務行為
• 用明確業務語言描述觸發條件和結果
• 讓舊功能 scenario 也與新需求同步調整，避免重複、過時

修改範例時的注意事項整理

1. 每次改寫都聚焦一條規則：Scenario 不能「包山包海」，否則維護和理解都會變困難。
2. 用業務語言取代技術細節：例如用「讀者預約圖書」而非「點擊 Reserve 按鈕」。
3. 只保留本質資料與邊界情境：剛開始可用真實資料釐清假設，最終應去除非本質細節。
4. 每加新功能時同步審查舊 scenario：確保現有情境能反映新行為，必要時分拆 scenario。
5. 情境名稱揭示業務意圖：名稱要能讓非技術同仁一眼看出「這條 scenario 是說明什麼行為規則」。
6. 不要為測試而 scenario，scenario 主要是溝通：讓所有利害關係人都能理解，測試自動化只是附加價值。
7. 情境簡潔、聚焦、易懂：短 scenario 才容易被審閱、討論和維護。

總結

每當 refactoring 舊場景或新功能導入時，務必用 BRIEF 原則自我檢查，讓 scenario 成為跨團隊、跨職能的溝通橋樑，而不只是測試檔案。重寫、調整 scenario 是產品演進的自然部分，不要害怕投入這些工，這是讓團隊知識不斷精煉、產品品質提升的關鍵。